I don't think making this public makes sense. @Javagedes do you have thoughts on this? Feels like a different paradigm is needed.

I could move this to the SDK instead?

Like this at sdk/patina/src/pi/dxe_services.rs?

/// Interface for dispatching DXE drivers.
///
/// Boot orchestrators use this to interleave controller connection
/// with driver dispatch.
pub trait DxeServices: Send + Sync + 'static {
    /// Run a single dispatch pass. Returns `true` if any drivers were dispatched.
    fn dispatch(&self) -> crate::error::Result<bool>;
}

Yeah, I don't think we want to make this public outside of the core. It leaks containment of functionality that the platform's top level main() function should not have access to, which could result in platforms doing bad things.

Based off of the current usage:

impl DxeServices for CoreDxeServices {
    fn dispatch(&self) -> patina::error::Result<bool> {
        CORE.dispatch()
    }
}

// Boot orchestration with connect-dispatch interleaving
add.component(BootDispatcher::new(
  SimpleBootManager::new(
    BootConfig::new(create_boot_path())
      .with_failure_handler(|| log::error!("Boot failed: all boot options exhausted")),
    ),
    CoreDxeServices,
));

I think one of these two options better lean into the patina component model via dependency injection:

1. Create a new service trait defined in the patina crate for either (1) only dispatch or (2) the entire dxe services table, and implemented in the core (Similar to the CoreMemoryManager), then consume it through dependency injection
2. Do the same as 1, but instead do it for configuration table functionality, then you can grab the dxe services configuration table and call dispatch from dxe_services

Thanks, I'll go with (1.) by making a new service trait instead. Would be something like CoreDxeDispatch, implemented like CoreMemoryManager

The platform binary will never touch dispatch() directly

I believe false means no drivers were dispatched, not necessarily that there are no more remaining drivers.

Why is this configurable? Can we not just always use the pi_dispatcher?

Probably for mocking.

Can't the whole trait just be mocked?

Fair :) I concur with @os-d we should just hardcode in the usage of the core instead of having the wrapper like this.

Also if you update init_memory to be &'static self (which I think is fair), then I think you could even do something like this:

pub(crate) struct CoreDxeDispatch<P: PlatformInfo>(&'static Core<P>);

// ...

component_dispatcher.add_service(dxe_dispatch_service::CoreDxeDispatch::new(self);

I'm not 100% confident in that though.